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DETAILED ACTION 
Information Disclosure Statement 

1 . The information disclosure statement (IDS) submitted on March 4, 2008 was filed after 
the mailing date of application on April 16, 2004. Submission is in compliance with provisions 
of 37 CFR 1.97. Accordingly, information disclosure statement is being considered by examiner. 

Response to Arguments 

2. Applicant's arguments, see p. 15, filed April 24, 2008, with respect to objections are 
persuasive. Objection to claims 1, 2, 22, 30-32, 45-47, 58, 63, 74, 75 has been withdrawn. 

3. Applicant's arguments filed April 24, 2008, with respect to 35 U.S.C. 102 and 35 U.S.C. 
103 rejections have been fully considered but they are not persuasive. 

4. Applicant argues specification states "memory or any other suitable storage medium that 
exists or may exist in the future." Specific examples (RAM, computer disk drive, non-volatile 
storage, optical memory, USB devices) of storage are listed in specification. One of ordinary 
skill will recognize that computer readable mediiim is clearly defined in specification (p. 16). 

In reply. Examiner points out "storage medium" and "computer readable medium" are 
not necessarily the same thing. Examiner maintains that specification does not appear to 
explicitly define "computer readable medium", and one of ordinary skill in the art would fairly 
determine "computer readable medium" to include signals or other forms of propagation and 
transmission media. Further, Claims 79-83 are directed to image processing application program 
interface embodied on computer readable media, and specification does not appear to explicitly 
describe that application program interface is embodied on the memory or storage medium that 
Applicant has referenced above. Claim 85 is directed to computer readable medium having 
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computer executable instructions, and specification does not appear to explicitly describe that 
computer executable instructions are stored in the memory or storage medium that Applicant has 
referenced above. So, Examiner maintains "computer readable medium" could include signals. 

5. Applicant argues specification doesn't define API as high level programming language. 
One of ordinary skill would understand API is application program interface and not equivalent 
to high level programming language because it is an interface and not a language (p. 17). 

In reply. Examiner points out one of ordinary skill in the art would define API as set of 
declarations of fimctions that an operating system, library or service provides to support requests 
made by computer programs. So, one of ordinary skill in the art would not interpret API to be a 
hardware interface, since it is a set of declarations of functions. Since API is a set of declarations 
of functions, one of ordinary skill in the art would consider API to be a data structure. Definition 
of "data structure" is "physical or logical relationship among data elements, designed to support 
specific data manipulation functions." Data structures per se are descriptive material per so and 
are not statutory because they are not capable of causing functional change in the computer. Such 
claimed data structures do not define any structural and fimctional interrelationships between 
data structure and other claimed aspects of invention which permit data structure's fimctionality 
to be realized (see MPEP 2106.01). So, API is directed to non-statutory subject matter. 

6. As per Claim 28, Applicant argues Grantham's (US006215495B1) "CompileAction" not 
"compilation", in its normal defined sense or as used by Applicant, because Grantham's 
"CompileAction" does not yield executables (p. 18). 

In reply. Examiner points out that definition of compiler is computer program that 
translates text written in computer language into another computer language. Grantham teaches 
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interpreter 111 modifies scene graph to suit specific graphics subsystem hardware 109. 
Interpreter 111 enables VRML file to be adapted to run on virtually any type of machine (c. 5, II. 
5-9). So interpreter 111 translates VRML file to another computer language that is able to be run 
on graphics subsystem hardware 109, and so interpreter 1 1 1 is considered to perform compiling. 
7. Applicant argues in Grantham, local processor (i.e. T' process) does not "indicate 
parameters associated with creation of resuh image." Local processor is merely making internal 
request of web server and web server provides appropriate VRML file. Cited "first process" in 
Grantham merely asks for VMRL file without any reference to or cognizance of claimed 
"creation of context", "creation of result image", or "parameters associated with result image". 
Internet server of Grantham performs function of creating VRML file (p. 19). 

Examiner points out Grantham teaches that VRML file that is requested instructs API 
1 12, and API is structured as collection of class hierarchies (c. 4, 11. 63-c. 5, 11. 23), including 
Graphics State classes that includes Context, Appearance, Material, Texture, and Tex Transform 
classes (c. 28, 11. 14-16). Context class maintains graphics state for particular graphics context (c. 
3, 11. 2-4). The other Graphics State classes define how result image is to be created (c. 8, 11. 38- 
46). So Graphics State classes indicate parameters associated with creation of result image. 
Draw Action class is used to draw scene (c. 7, 11. 31-33). Since VRML file that is requested 
includes this information about Context class, Graphics State classes, and Draw Action class, 
VRML file that is requested requests creation of context (Context class), requests creation of 
result image (DrawAction class), and includes information that indicates parameters associated 
with creation of result image (Graphics State classes). Since 1^* process requests this VRML file. 
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1st process is considered to request creation of context, request creation of result image, and 
indicate parameters associated with creation of result image. 

8. As per Claim 74, Applicant argues 1^* process of Grantham is web browser and is not 
"requesting creation of an image." Web browser is "initiating a request which is routed by 
input/output (I/O) device 107 through the internet 106 to server 101 ." Web browser requesting 
information from server is not same as "a first process running on a CPU requesting creation of 
an image." Web browser does not have "a graphics services resource, responding to said request" 
because intemet server 101 is what responds to request disclosed in Grantham (p. 21). 

In reply, Grantham recites "processor 108 of computer system 116 initiating a request 
which is routed by input/output (I/O) device 107 through the Intemet 106 to server 101" (c. 4, 11. 
63-66). So first process is running on CPU 116 requesting creation of image. Grantham teaches 
request results in VRML file being transmitted to computer system 116, and VRML file instructs 
API 1 12, and API is structured as collection of class hierarchies (c. 4, 11. 63-c. 5, II. 23), 
including CompileAction class 403 that compiles specified subgraph into data structure which is 
more efficient for traversals (c. 7, 11. 50-57). So, ultimately API 1 12 responds to request by 
running first routine on CPU 116, first routine for optimizing graph representing the image (c. 4, 
11. 63-c. 5, 11. 23; c. 7, 11. 50-57), and so API 112 is considered to be graphics services resource. 

9. As per Claim 75, Applicant argues instant specification states domain of definition is 
representation of all places in image that are explicitly defined and not transparent. Scene graph 
of Boudier is model with nodes representing features of second and edges representing 
associations between connected components. 1^* graph's global domain of definition is not input 
scene graph of Boudier (US006995765B2). Bounding box of Boudier is not global region of 
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interest, which is portion of input image that is necessary to compute given DOD, as stated in 
instant specification (p. 22). 

In response to applicant's argument that the references fail to show certain features of 
applicant's invention, it is noted that the features upon which applicant relies (i.e., domain of 
definition is representation of all places in image that are explicitly defined and not transparent, 
region of interest is portion of input image that is necessary to compute given DOD) are not 
recited in the rejected claim(s). Although the claims are interpreted in light of the specification, 
limitations from the specification are not read into the claims. See In re Van Geuns, 988 
F.2d 1181,26USPQ2d 1057 (Fed. Cir. 1993). 

10. As per Claim 79, Applicant argues API discussed by McCrossin (US00660840B1) does 
not disclose image processing API as set forth in Claim 79 rather, McCrossin's only APIs are 
"read" and "write" APIs. McCrossin does not teach specific bundle of API services as claimed 
by merely stating API call or procedure call is used. McCrossin does not teach APIs to filter 
object, APIs to image objects, APIs to context objects and APIs to vector objects (p. 23-24). 

In reply. Examiner points out McCrossin describes "an application calls the 
transformation object using a procedure call or API call" (c. 7, 11. 33-34), and "transform object 
103 determines an actual image vector 139. ..image request vector 127. ..is compared to actual 
image vector 139 to determine what filters are needed" (c. 6, 11. 51-56). So, McCrossin does 
teach APIs to filter objects and other objects, and does not only comprise of read and write APIs. 

1 1 . Applicant argues simply describing format of image as taught by McCrossin does not 
encompass requirements of image objects and context objects. Specification teaches context may 
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be created using "tools that allow definition of an object in memory." This does not mean that 
any definition of object in memory is creating a context (p. 24-25). 

In reply, according to Applicant's disclosure, context is space such as defined place in 
memory in which result of filtering operation resides (p. 9, [0045]). McCrossin teaches buffer 
107 in which result of filtering operation resides (c. 5, 11. 59-60; c. 6, 11. 51-56), so teaches 
context creation. 

12. Applicant argues such bundle of API services as claimed is absent fi-om McCrossin 
because major purpose of McCrossin is to isolate application layer from task of doing file format 
conversion (p. 25). 

In reply, Examiner points out that major purpose of McCrossin is not really about 
isolating application layer from task of doing file format conversion, but actually the major 
purpose is to use plurality of filters for performing file format conversion, and comparing 
parameter values to determine whether or not filter is needed for file format conversion to 
efficiently transform format without performing any unnecessary work (c. 11, 11. 23-36; c. 1, 11. 
50-c. 2, 11. 2). As discussed above, McCrossin does teach API services related to filter objects. 

13. As per Claim 84, Applicant argues McCrossin teaches retrieving filter objects from pre- 
existing library, but does not teach API to create filter objects. McCrossin does not teach creating 
new filter object but teaches creating "new tile object" and filters are only pushed and popped 
from filter stack. Adding pre-existing filters selected fi-om filter library to a stack such that they 
can be applied in particular order cannot be interpreted as creating new filters (p. 26-27). 

In reply. Claim 84 recites "create filter objects". Since McCrossin teach creating new file 
object for filter stack (c. 8, 11. 25-37), this is considered to be creating filter object. 
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14. As per Claim 1 , Applicant argues McCrossin simply translates images from one format to 
another and is silent regarding multiple processes and specific division of work between multiple 
processes (p. 28-29). 

In reply, Examiner points out Grantham is used to teach multiple processes and specific 
division of work between multiple processes. McCrossin is merely used to teach 1^* process 
defines relationship between filter and initial image. 

15. As per Claim 22, Applicant argues Grantham is silent as to multiple processes running on 
first microprocessor because it is directed to rendering 3D image in across internet inside of web 
browser (p. 31). 

Examiner points out Grantham teaches that the rendering of 3D image actually occurs in 
graphics subsystem 109 that is in computer 1 16 system (first microprocessor) (c. 5, 11. 5-1 1). 

16. Applicant argues McCrossin does not disclose data structure comprising relationship 
between image and filter via transform object 103 (p. 31). 

In reply. Examiner points out Fig. 6 of McCrossin shows transform object 103 (data 
structure) comprises image request vector 127 that is compared to actual image vector to 
determine what filters are needed (c. 6, 11. 46-c. 7, 11. 9). Since transform object 103 compares 
actual image vector to determine what filters are needed, this means that transform object 103 
determines from image what filters are needed, and so transform object 103 (data structure) 
comprises relationship between image and filter. 

Claim Rejections - 35 USC § 101 

17. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useM process, machine, manufacture, or composition of matter, or 
any new and useM improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 
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18. Claims 79-85 are rejected under 35 U.S.C. 101 because the claimed invention is directed 

to non- statutory subject matter. 

19. Claims 79-83 are directed to image processing application program interface embodied 
on one or more computer readable media. Specification does not appear to explicitly define 
"computer readable media". Since specification does not define "computer readable media", one 
of ordinary skill in the art would fairly determine image processing application program interface 
could be embodied on "computer readable media" that could include signals or other forms of 
propagation and transmission media in order to transmit image processing application program 
interface. Signals or other forms of propagation and transmission media fail to be appropriate 
manufacture under 35 U.S.C. 101 in context of computer-related inventions, and thus "computer 
readable media" is directed to non-statutory subject matter (see MPEP 2106 IV). 

20. Claim 84 is directed to application program interface. One of ordinary skill in the art 
would define API as set of declarations of functions that an operating system, library or service 
provides to support requests made by computer programs. Since API is a set of declarations of 
functions, one of ordinary skill in the art would consider API to be a data structure. Definition of 
"data structure" is "physical or logical relationship among data elements, designed to support 
specific data manipulation functions." Data structures per se are descriptive material per se and 
are not statutory because they are not capable of causing fimctional change in the computer. Such 
claimed data structures do not define any structural and functional interrelationships between 
data structure and other claimed aspects of invention which permit data structure's functionality 
to be realized (see MPEP 2106.01). So, API is directed to non-statutory subject matter. 
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21 . Claim 85 is directed to computer-readable medium having computer executable 
instructions. Specification does not appear to explicitly define "computer-readable medium". So, 
one of ordinary skill in the art would fairly determine "computer-readable medium" could 
include signals or other forms of propagation and transmission media in order to transmit the 
instructions. Signals or other forms of propagation and transmission media fail to be appropriate 
manufacture under 35 U.S.C. 101 in context of computer-related inventions, and thus "computer- 
readable medium" is directed to non-statutory subject matter (see MPEP 2106 IV). 

Claim Rejections - 35 USC § 102 

22. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of appUcation for patent in the United States. 

(e) the invention was described in (1) an application for patent, published under section 1 22(b), by another filed in the 
United Slates before the invention by the appUcant for patent or (2) a patent granted on an appUcation for patent by 
another filed in the United States before the invention by the applicant for patent, except that an international 
application filed under the treaty defined in section 351(a) shall have the effects for purposes of this subsection of an 
application filed in the United States only if the international appUcation designated the United States and was 
published under Article 21(2) of such treaty in the English language. 

23. Claims 28, 29, 38, 39, 43, 44, 53, 54, and 74 are rejected under 35 U.S.C. 102(b) as being 

anticipated by Grantham (US006215495B1). 

24. As per Claim 28, Grantham teaches processor 108 initiates request which is routed to 
server 101. When server 101 receives such request, processor 102 retrieves appropriate VRML 
file. VRML file that is requested instructs API 1 12 to make a number of function calls to various 
graphics engines 1 13 for performing desired fiinctions on persistent data objects 118. API is 
structured as collection of class hierarchies (c. 4, 11. 63 -c. 5, 11. 23), including Graphics State 
classes that includes Context, Appearance, Material, Texture, TexTransform classes (c. 28, 11. 
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14-16). Context class maintains graphics state for particular graphics context (c. 3, 11. 2-4). The 
other Graphics State classes define how result image is to be created (c. 8, 11. 38-46). So 
Graphics State classes indicate parameters associated with creation of result image. DrawAction 
class is used to draw scene (c. 7, 11. 31-33). Since VRML file that is requested includes this 
information about Context class, Graphics State classes, DrawAction class, VRML file that is 
requested requests creation of context (Context class), requests creation of result image 
(DrawAction class), and includes information that indicates parameters associated with creation 
of result image (Graphics State classes). Since 1^ process requests this VRML file, 1st process is 
considered to request creation of context, request creation of result image, and indicate 
parameters associated with creation of result image. So Grantham teaches method of creating 
result image having 1^* process requesting creation of context; 1^* process requesting creation of 
result image; 1^* process indicating parameters associated with creation of result image; 1^* 
process requesting result image be rendered to context (c. 4, 11. 63-c. 5, 11. 23; c. 28, 11. 14-16; c. 
3, 11. 2-24; c. 8, 11. 38-46; c. 7, 11. 31-33); 2"** process servicing requests of 1^' process, servicing 
comprising steps of optimizing graph representing result image; compiling optimized graph; 
causing rendering of compiled optimized graph into context (c. 5, 11. 2-23; c. 4, 11. 55-58; c. 7, 11. 
50-57; c. 3, 11. 2-4). Interpreter 111 modifies scene graph to suit specific graphics subsystem 
hardware. Interpreter enables VRML file to be adapted to run on virtually any type of machine 
(c. 5, 11. 5-9). So interpreter translates VRML file to another computer language that is able to be 
run on graphics subsystem hardware, so interpreter is considered to perform compiling. 
25. As per Claim 29, Grantham teaches creation of result image comprises editing pre- 
existing image (c. 1 1, 11. 22-25). 
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26. As per Claim 38, Grantham teaches l*** process is application program (1 12) (c. 5, 11. 2-5). 

27. As per Claim 39, Grantham teaches second process comprises suite of graphics services 
functions (c. 3, 11. 1-16; c. 5, 11. 2-19). 

28. As per Claim 43, it is similar in scope to Claim 28, except it has additional limitation that 
1st process and 2nd process are running on first microprocessor, and rendering occurs on second 
microprocessor. Grantham teaches first process (requesting) and second process (compiling) are 
running on first microprocessor (108), and rendering occurs on second microprocessor (109) (c. 
4, 11. 63-c. 5, 11. 23; c. 7, 11. 50-57). So Claim 43 is rejected under same rationale as Claim 28. 

29. As per Claims 44, 53, and 54, these claims are similar in scope to Claims 29, 38, and 39 
respectively, and therefore are rejected under the same rationale. 

30. As per Claim 74, Grantham teaches rendering image, 1^* process running on CPU 107 
requesting creation of image; graphics services resource 109, responding to request by running 
1^' routine on CPU, 1^^ routine for optimizing graph representing image; 1^* process requesting 
rendering of image to specified context; graphics services resource causing rendering of graph 
representing image, rendering occiirring on GPU (c. 4, 11. 55-58, 63-67; c. 5, 11. 1-23, 61-67). 
Grantham recites "processor 108 of computer system 116 initiating a request which is routed by 
input/output (I/O) device 107 through the Internet 106 to server 101" (c. 4, 11. 63-66). So first 
process is running on CPU 116 requesting creation of image. Grantham teaches request results in 
VRML file being transmitted to computer system 116, and VRML file instructs API 112, and 
API is structured as collection of class hierarchies (c. 4, 11. 63-c. 5, 11. 23), including 
CompileAction class 403 that compiles specified subgraph into data structure which is more 
efficient for traversals (c. 7, 11. 50-57). So, ultimately API 1 12 responds to request by running 
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first routine on CPU 116, first routine for optimizing graph representing the image (c. 4, 11. 63 -c. 
5, 11. 23; c. 7, 11. 50-57), and so API 1 12 is considered to be graphics services resource. 

3 1 . Thus, it reasonably appears that Grantham describes or discloses every element of Claims 
28, 29, 38, 39, 43, 44, 53, 54, and 74 and therefore anticipates the claims subject. 

32. Claims 75 and 78 are rejected under 35 U.S.C. 102(e) as being anticipated by Boudier 
(US006995765B2). 

33. As per Claim 75, Boudier teaches converting 1^ image representation into 2°'' image 
representation, comprising creating 1^* graph associated with 1^* image representation (c. 1, 11. 29- 
36; c. 2, 11. 31-34; c. 3, 11. 61-63) where software routines for creating such graph execute on 
CPU (504) (c. 1, 11. 49-51; c. 6, 11. 34-38), determining intersection of 1^' graph's global domain 
of definition (input scene graph) and global region of interest (bounding box) (c. 9, 11. 12-21); 
resolving 1^ node in 1^* graphic by running software routines on CPU to determine if 1st node 
may be combined with 2"'' node (c. 9, U. 40-53; c. 5, 11. 33-37) and create program steps for 
calculating and storing only portions of any intermediary image that relate to intersection (c. 9, 11. 
12-21), program steps for compilation on CPU, execution on GPU (c. 5, 11. 33-37; c. 6, 11. 19-21). 

34. As per Claim 78, Boudier teaches first node is root node (c. 8, 11. 10-1 1). 

35. Thus, it reasonably appears that Boudier describes or discloses every element of Claims 
75 and 78 and therefore anticipates the claim subject. 

36. Claims 79-84 are rejected under 35 U.S.C. 102(e) as being anticipated by McCrossin 
(US006600840B1). 

37. As per Claim 79, McCrossin teaches application calls transformation object using API 
call (c. 7, 11. 33-35). Transform object 103 determines actual image vector 139, which describes 
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format of image to be read or written (c. 6, U. 5 1-53). Since this describes format of image, this is 
related to image objects and context objects. Image request vector is received from application 
and is compared to actual image vector 139 to determine what filters are needed (c. 6, 11. 53-56). 
Filters are accessed by transformation object from filter library. Filter library contains number of 
different filters available for performing various image transformations (c. 6, 11. 59-62). Pointer 
to filter vector in filter object 150 points to filter vector 154, which in depicted example is crop 
filter (c. 7, 11. 19-21). So, McCrossin teaches image processing API and API services related to 
filter objects, API services related to image objects, API services related to context objects and 
APT services related to vector objects. McCrossin uses API to call at filters. So, McCrossin 
teaches image processing application program interface embodied on one or more computer 
readable media (c. 6, 11. 25-30), having 1^* group of services related to filter objects (c. 6, 11. 59- 
67); 2°'* group of service related to image objects; 3^** group of services related to context objects 
(c. 5, 11. 59-60; c. 6, 11. 51-56); 4"" group of services related to vector objects (c. 7, 11. 14-17). 

38. As per Claim 80, McCrossin teaches 1^' group of services have 1^* fiinctions to create 
fiher objects; fimctions to set filter object parameters; 3^** fimctions to obtain filter object 
output (c. 2, 11. 25-32). 

39. As per Claim 81, McCrossin teaches 2"'' group of services have 1*** function to create 
image objects (c. 6, 11. 51-56); 2°'* functions to render an image object to context object (c. 9, 11. 
7-18). 

40. As per Claim 82, McCrossin teaches 3^** group of services have 1^ fiinctions to create 
context objects (c. 5, 11. 46-67). 
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41 . As per Claim 83, McCrossin teaches 4**" group of services comprise 1**' functions to create 
vector objects (c. 7, 11. 15-32). 

42. As per Claim 84, McCrossin teaches application calls transformation object using API 
call (c. 7, II. 33-35). Filters are accessed by transformation object from filter library 143. Filter 
library contains number of different filters available for performing various image 
transformations (c. 6, 11. 59-62). Transform object adds filter to filter stack to create new filter 
object (c. 6, II. 51-58; c. 8, U. 25-37). Since McCrossin teach creating new file object for filter 
stack (c. 8, II. 25-37), this is considered to be creating filter object. According to Apphcant's 
disclosure, image, more commonly, may be created from another image by applying filter to 
existing image ([0057], p. 12). So, McCrossin teaches API functions to create image objects; API 
functions to create filter objects. Transform object 103 determines actual image vector 139, 
which describes format of image to be read or written (c. 6, II. 51-53). According to Applicant's 
disclosure, creating context is derived from tools that allow definition of object in memory 
([0055], p. 1 1). Since actual image vector describes format of image to be read or written, this 
allows definition of object in memory, so is considered to create context objects, so McCrossin 
teaches API functions to create context objects. Pointer to filter environment in filter object 150 
points to memory 156, which contains information which may be used by filter vector 154 in 
converting or transforming image data (c. 7, 11. 21-24), and so McCrossin does teach API 
functions to set filter object parameters. Filters are employed by transformation object 103 to 
provide necessary fransformation of image data to return image data in form as specified in 
image request vector 127 (c. 6, II. 66-c. 7, II. 2), and so McCrossin teaches API functions to 
obtain filter object output; API fimctions to convert image objects to context objects. So, 
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McCrossin teaches application program interface for facilitating image processing (c. 6, 11. 25- 
30), API having functions to create image objects; create context objects (c. 6, 11. 51-53); create 
filter objects; set filter object parameters; obtain filter object output (c. 2, 11. 25-32); convert 
image objects into context objects (c. 6, 11. 51-53). 

43. Thus, it reasonably appears that McCrossin describes or discloses every element of 
Claims 79-84 and therefore anticipates the claims subject. 

Claim Rejections - 35 USC § 103 

44. The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identicaUy disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

45. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 
(1966), that are applied for establishing a background for determining obviousness under 35 
U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness 
or nonobviousness. 

46. Claims 1, 2, 8, 11, 12, 14-20, 36, 37, 40, 41, 51, 52, 55, 56, 58, 61-63, 66-73, and 85 are 
rejected under 35 U.S.C. 103(a) as being unpatentable over Grantham (US006215495B1) and 
McCrossin (US006600840B1). 

47. As per Claim 1, Grantham teaches processor 108 initiates request which is routed to 
server 101. When server 101 receives such request, processor 102 retrieves appropriate VRML 
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file. VRML file instructs API 112 to make a number of function calls to various graphics engines 
1 13 for performing desired fiinctions on persistent data objects 118. Interpreter 111 modifies 
scene graph to suit specific graphics subsystem hardware 109. Hence, interpreter 111 enables 
VRML file to be adapted to run on graphics subsystem hardware (c. 4, 11. 63-c. 5, 11. 1 1). API is 
structured as collection of class hierarchies. Nodes and graphics states are assembled into 
cohesive scene graph (c. 5, 11. 18-23). Graphics State classes include Texture class 504 that 
defines how image is filtered (c. 28, 11. 10-16; c. 11, 11. 22-25). Outside Scene Graph classes 
include CompileAction class 403 that compiles specified subgraph into data structure which is 
more efficient for traversals (c. 28, 11. 25-27, 29-30; c. 7, 11. 50-57). So filter is part of scene 
graph (c. 5, 11. 18-23; c. 28, 11. 10-16; c. 11, 11. 22-25) that is run on graphics subsystem hardware 
(c. 5, 11. 5-1 1). Before scene graph is run on graphics subsystem hardware (c. 5, 11. 5-1 1), 
interpreter 111 modifies scene graph to suit specific graphics subsystem hardware 109. 
Interpreter 1 1 1 enables VRML file to be adapted to run on virtually any type of machine (c. 5, 11. 
5-9). So interpreter 111 translates VRML file to another computer language that is able to be run 
on graphics subsystem hardware 109, and so interpreter 1 1 1 is considered to perform compiling, 
and compiled program includes filter. So VRML file requested by processor 108 (c. 4, 11. 63-c. 5, 
11. 1 1) includes filter (c. 5, 11. 18-23; c. 28, 11. 10-16; c. 11, 11. 22-25), and processor 108 requests 
filter fi-om compiling process since program needs to be compiled before it is run on graphics 
system hardware. So Grantham teaches method of editing initial image, having steps of 1**^ 
process requesting (c. 4, 11. 63-c. 5, 11. 1 1) filter from 2°'* process; related filter and initial image 
comprising program, 2°'* process compiling program, yielding compiled program; running at 
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least portion of compiled program to apply function of filter to image (c. 5, 11. 5-11, 18-23; c. 28, 
II. 10-16; c. 1 1, II. 22-25; c. 7, II. 50-57), yielding pixel-image result (c. 5, 11. 9-11). 

However, Grantham does not teach 1^* process defines relationship between filter and 
initial image. But, McCrossin teaches editing initial image, 1^* process requesting filter fi-om 
process; process defining relationship between filter and initial image (c. 6, 11. 46-c. 7, 11. 9). 

It would have been obvious to one of ordinary skill in the art at the time of invention by 
applicant to modify Grantham so first process defines relationship between filter and initial 
image because McCrossin suggests reducing amount of processing required to convert image 
data from original or input format into desired output format (c. 1, 11. 54-57; c. 2, 11. 3-24). 

48. As per Claim 2, Grantham teaches optimizing the program (c. 4, 11. 55-58). 

49. As per Claim 8, Grantham teaches compiled program has component for 1^* (108, Fig. 1) 
and 2""* microprocessors (109) (c. 4, II. 63-c. 5, II. 11; c. 7, II. 50-57). 

50. As per Claim 11, Grantham teaches 1^' microprocessor is CPU (108, Fig. 1) and 2°'* 
microprocessor is GPU (109) (c. 4, II. 63-c. 5, U. 1 1). 

51. As per Claim 12, Grantham teaches 1^* and microprocessors are both CPUs (108, 102, 
Fig. l;c.4, II. 63-c. 5, II. 11). 

52. As per Claim 14, Grantham teaches initial image is only color (c. 12, II. 45-52). 

53. As per Claim 15, Grantham teaches l*** process is application program (1 12) (c. 5, 11. 2-5). 

54. As per Claim 16, Grantham teaches 2°'* process has suite of graphics services functions 
(c. 3, II. 1-16; c. 5, II. 2-19). 

55. As per Claim 17, Grantham does not explicitly teach operating system comprises second 
process. However, McCrossin teaches this limitation (c. 4, II. 2-5). 
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It would have been obvious to one of ordinary skill in the art at the time of invention by 
applicant to modify device of Grantham so operating system comprises second process because 
McCrossin suggests operating system is needed in order for processor to function (c. 4, 11. 2-5). 
56. As per Claim 18, Grantham teaches VRML is high level programming language (c. 1, 11. 
63-67). Processor 108 initiates request which is routed to server 101. When server 101 receives 
such request, processor 102 retrieves appropriate VRML file. VRML file instructs API 1 12 to 
make a number of function calls to various graphics engines 1 13 for performing desired 
functions on persistent data objects 118. Interpreter 111 modifies scene graph to suit specific 
graphics subsystem hardware 109. Hence, interpreter 1 1 1 enables VRML file to be adapted to 
run on graphics subsystem hardware (c. 4, 11. 63-c. 5, 11. 1 1). API is structured as collection of 
class hierarchies. Nodes and graphics states are assembled into cohesive scene graph (c. 5, 11. 18- 
23). Graphics State classes include Texture class 504 that defines how image is filtered (c. 28, 11. 
10-16; c. 1 1, 11. 22-25). So high level programming language VRML (c. 1, 11. 63-67) is 
interpreted by interpreter 111 into lower level programming language so that it is adapted to run 
on graphics subsystem hardware (c. 5, 11. 5-1 1), this lower level programming language includes 
filter (c. 5, 11. 18-23; c. 28, 11. 10-16; c. 11, 11. 22-25). So 1'* process requests filter by requesting 
VRML file (c. 4, 11. 63-67), which is high level programming language (c. 1, 11. 63-67), 2°'' 
process responds by interpreting high level programming language into lower level programming 
language (c. 5, 11. 5-1 1) including filter so that filtering is adapted to run on graphics subsystem 
hardware (c. 5, 11. 18-23; c. 28, 11. 10-16; c. 1 1, 11. 22-25). So 1'* process requests high-level filter 
(c. 4, 11. 63-67; c. 1, 11. 63-67) and process responds with object representing lower-level filter 
(c. 5, 11. 5-11, 18-23; c. 28, 11. 10-16; c. 11, 11. 22-25). 
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57. As per Claim 19, Grantham shows processor 108, interpreter 111, and API 1 12 are part of 
computer system 116 in Fig. 1. So first process and second process run on CPU (108, 111, 112) 
and compiled program runs on GPU (109) (c. 4, II. 63-c. 5, II. 23; c. 7, II. 50-57). 

58. As per Claim 20, it is similar in scope to Claim 19, so is rejected under same rationale. 

59. As per Claim 36, Grantham teaches first process requests output of graph 
programmatically assembled by first process (c. 4, II. 63-c. 5, II. 23). 

However, Grantham does not explicitly teach graph has one or more pre-defined filters. 
But, McCrossin teaches this (c. 6, II. 59-67). This would be obvious for reasons for Claim I. 

60. As per Claim 37, Grantham teaches first process programmatically assembled graph in 
cooperation with second process (compiling) (c. 4, II. 63-c. 5, II. 23; c. 7, U. 50-57). 

61 . As per Claims 40-41, these claims are each similar in scope to Claim 17, and so are 
rejected under same rationale. As per Claims 51, 52, 55, and 56, these claims are similar in scope 
to Claims 36, 37, 40, and 41 respectively, and so are rejected under the same rationale. 

62. As per Claim 58, Grantham teaches interpreter III enables VRML file to be adapted to 
run on graphics system hardware 109 (c. 5, II. 5-9). VRML is high level programming language 
(c. I, II. 63-67). So Grantham teaches providing high level interface (1 1 1) to graphics processing 
resource (109) (c. 5, 11. 5-9; c. 1, 11. 63-67) having 1**' process requesting performance of task 
through 1 or more function calls serviced by graphics processing resource (c. 4, 11. 63-c. 5, 11. 
23), function calls selected from 1 or more of following options, (i) creating of image (Graphics 
State classes) (c. 28, II. 14-16; c. 8, II. 37-46; c. 7, II. 31-33), (iv) asking for output of filter or 
another filter (504; c. 1 1, II. 22-25), (v) creating context (302); (vi) rendering image to context or 
another context; request having object associated therewith, object comprising one of following: 
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context (c. 5, II. 61-67), image (c. 28, II. 14-16; c. 8, II. 37-46; c. 7, II. 31-33), filter (c. II, II. 22- 
25), or vector (c. 26, II. 20-22); graphics processing resource servicing request (c. 5, II. 2-23). 

However, Grantham does not explicitly teach request defines relationship between at 
least one of fiinctions and one of objects. However, McCrossin teaches this limitation (c. 6, 11. 
46-c. 7, II. 9). This would be obvious for the same reasons given in the rejection for Claim I. 

63. As per Claim 61, Grantham teaches creating graph representing image (c. 2, II. 52-58). 

64. As per Claim 62, Grantham teaches optimizing graph (c. 4, 11. 55-59; c. 5, 11. 2-1 1). 

65. As per Claims 63, 66, and 67, these claims are similar in scope to Claims 58, 61, and 62 
respectively, and so are rejected under same rationale. 

66. As per Claim 68, Grantham does not explicitly teach function calls include option of 
creating filter. But, McCrossin teaches this (c. 6, 11. 59-67). This is for reasons for Claim 1. 

67. As per Claim 69, Grantham does not explicitly teach fiinction calls include option of 
setting arguments associated with filter. However, McCrossin teaches this limitation (c. 7, II. 1-7; 
c. 6, II. 9-21). This would be obvious for the same reasons given in the rejection for Claim 1. 

68. As per Claim 70, it is similar in scope to Claim 69, so is rejected under same rationale. 

69. As per Claim 7 1 , Grantham does not teach another object associated with request has 
filter. But, McCrossin teaches this (c. 6, 11. 59-67). This is obvious for reasons for Claim I . 

70. As per Claim 72, Grantham does not teach another object associated with request is 
vector. But, McCrossin teaches this (c. 7, 11. 14-17). This is obvious for reasons for Claim I . 

71 . As per Claim 73, it is similar in scope to Claim 72, so is rejected under same rationale. 

72. As per Claim 85, Grantham teaches computer executable instructions for performing 
method recited in Claim 1 (c. 4, 11. 63-C.5, 11. 23). 
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73. Claim 3 is rejected under 35 U.S.C. 103(a) as being unpatentable over Grantham 
(US006215495B1) and McCrossin (US006600840B1) in view of Levy (US 20020033844A1). 

Grantham and McCrossin are relied upon for teachings for Claim 2. 

But, Grantham and McCrossin do not teach optimizing includes step of using cache look- 
up to see if pixel-image result is already in cache. But, Levy teaches this [0184, 0021, 0038]. 

It would have been obvious to one of ordinary skill in the art at the time of invention by 
applicant to modify Grantham, McCrossin so optimizing includes using cache look-up to see if 
pixel-image result is already in cache because Levy teaches avoiding repeated read operations on 
same content [0184]. 

74. Claims 4-6 and 21 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Grantham (US006215495B1) and McCrossin (US006600840B1) in view of Boudier 
(US006995765B2). 

75. As per Claim 4, Grantham and McCrossin are relied on for teachings relative Claim 2. 
But, Grantham and McCrossin do not teach optimizing includes step of calculating 

intersection, intersection representing area where pixel-image result is both defined and in result 
region requested of 2°'* process. But, Boudier teaches step of optimizing includes step of 
calculating intersection, intersection representing area where pixel-image result is both defined 
(input scene graph) and in result region requested of 2°'* process (bounding box) (c. 9, 11. 12-21). 

It would have been obvious to one of ordinary skill in the art at the time of invention by 
applicant to modify Grantham, McCrossin so optimizing includes calculating intersection, 
intersection representing area where pixel-image result is both defined and in result region 
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requested of 2^'^ process because Boudier teaches removing unnecessary regions, which reduces 
traversal time (c. 9, 11. 12-21). 

76. As per Claim 5, Grantham does not teach step of using calculated intersection to limit 
number of pixels that require calculation during running of compiled program. However, 
Boudier teaches step of using calculated intersection (intersection of input scene graph and 
bounding box) to limit number of pixels that require calculation during running of compiled 
program (c. 9, 11. 12-21; c. 8, 11. 52-53). This would be obvious for reasons for Claim 4. 

77. As per Claim 6, Grantham doesn't teach using calculated intersection to limit amount of 
memory necessary for storing calculated images. Boudier teaches memory usage is increased 
during actual calculating of intersection due to creation of bounding volumes. But, after creation 
of bounding boxes, after the intersection is calculated, the unnecessary bounding boxes are 
removed. Bounding box is used for view fiiistum culling algorithm, so data outside of bounding 
box is culled out, so only data inside bounding box needs to be stored, so calculated intersection 
(intersection of input scene graph and bounding box) is used to limit amount of memory 
necessary for storing calculated images (c. 9, 11. 12-21). This is obvious for reasons for Claim 4. 

78. As per Claim 21, it is similar in scope to Claim 19, so is rejected under same rationale. 

79. Claims 7, 9, 60, and 65 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Grantham (US006215495B1) and McCrossin (US006600840B1) in view of Parikh 
(US006411301B1). 

80. As per Claim 7, Grantham and McCrossin are relied on for teachings relative to Claim 1 . 
However, Grantham and McCrossin do not teach compiled program is for single 

microprocessor. However, Parikh teaches single microprocessor that emulates graphics 
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processing (c. 26, 11. 29-62). So, Grantham can be modified so only single microprocessor is used 
instead of using separate graphics processor (c. 5, 11. 2-23) so compiled program of Grantham (c. 
7, 11. 50-57) is for single microprocessor, as suggested by Parikh. 

It would have been obvious to one of ordinary skill in the art at the time of invention by 
applicant to modify Grantham and McCrossin so compiled program is for single microprocessor 
because Parikh suggests advantage of still being able to perform graphics processing even when 
graphics processor for which software is written for is not available (c. 26, 11. 29-62). 

81. As per Claim 9, Grantham does not teach single microprocessor is CPU. However, Parikh 
teaches this limitation (c. 26, 11. 29-62). This would be obvious for reasons given for Claim 7. 

82. As per Claim 60, Grantham doesn't teach request is serviced using emulator to run GPU 
program on CPU. But, Parikh teaches this (c. 26, 11. 29-62). This is obvious for reasons for Claim 
7. 

83. As per Claim 65, it is similar in scope to Claim 60, so is rejected under same rationale. 

84. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over Grantham 
(US006215495B1), McCrossin (US006600840B1), and Parikh (US00641 1301B1) in view of 
Doyle (US006867779B1). 

Grantham, McCrossin, and Parikh are relied on for teachings relative to Claim 7. 

However, Grantham, McCrossin, and Parikh do not teach single microprocessor is 
programmable GPU. However, Doyle teaches dividing up rendering between CPU and GPU 
based on progress of one device of two devices (c. 1, 11. 20-26; c. 2, 11. 1-3). So, if CPU is busy, 
rendering is only performed in GPU. So, single microprocessor is programmable GPU. 
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It would have been obvious to one of ordinary skill in the art at the time of invention by 
applicant to modify Grantham, McCrossin, Parikh so single microprocessor is programmable 
GPU because Doyle teaches using device that would most quickly process command to process 
command (c. 1, 11. 20-26). 

85. Claim 13 is rejected under 35 U.S.C. 103(a) as being unpatentable over Grantham 
(US006215495B1) and McCrossin (US006600840B1) in view of Nelson (US006801202B2). 

Grantham and McCrossin are relied on for teachings for Claim 8. 

But, Grantham and McCrossin do not teach 1st and 2nd microprocessors are both GPUs. 
But, Nelson teaches API to generate commands and graphics data, and these commands are 
processed by 1st and second microprocessors that are both GPUs (c. 8, 11. 32-42, 67; c. 9, 11. 1-3). 

It would have been obvious to one of ordinary skill in the art to modify devices of 
Grantham and McCrossin so 1st and 2nd microprocessors are both GPUs because Nelson 
suggests advantage of increased graphics performance (c. 3, 11. 47-c. 63). 

86. Claims 22, 23, and 25-27 are rejected iinder 35 U.S.C. 103(a) as being unpatentable over 
Grantham (US006215495B1) and McCrossin (US006600840B1) in view of Hoppe 
(US006919906B2). 

87. As per Claim 22, Grantham teaches editing initial image, 1 microprocessor (108, 111, 
112, Fig. 1) running 1^* process and 2"'' process (compiling) for servicing requests from first 
process (c. 4, 11. 63-c. 5, 11. 11; c. 7, 11. 50-57). API is structured as collection of class hierarchies 
(c. 5, 11. 16-23) that include Texture class 504 that defines how image is filtered (c. 1 1, 11. 22-25). 
So filter is in API (c. 5, 11. 16-23; c. 1 1, 11. 22-25), and API 1 12 is stored in memory 1 10, as 
shown in Fig. 1 . So memory 1 10 is for storing filter, 2°'* memory for storing data structure 
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comprising information used in 1*^ process (c. 5, 11. 16-23; c. 1 1, 11. 22-25; Fig. 1) (1**' and 2°'' 
memories are same, as recited in Claim 23); 2°'* microprocessor 109 for running program created 
using data structure; outputting pixel image resulting from running program (c. 5, 11. 2-1 1). 

But, Grantham doesn't teach data structure has relationship between initial image and 
filter. But, McCrossin teaches data structure 1 03 has relationship between initial image and 
specific filter (image request vector 127 is received from application 101 and is compared to 
actual image vector to determine what filters are needed, c. 6, 11. 46-c. 7, 11. 9; application calls 
the transformation object using API call, c. 7, 11. 33-35). Fig. 6 shows fransform object 103 (data 
structure) comprises image request vector 127 that is compared to actual image vector to 
determine what filters are needed (c. 6, 11. 46-c. 7, 11. 9). Since transform object 103 compares 
actual image vector to determine what filters are needed, this means that fransform object 103 
determines from image what filters are needed, and so fransform object 103 (data structure) 
comprises relationship between image and filter. This is obvious for reasons for Claim 1 . 

But, Grantham, McCrossin don't teach 3'^'' memory for storing pixel image resulting from 
running program. But, Hoppe teaches API (c. 2, 11. 20-26) for filtering (c. 1, 11. 34-36), 3"* 
memory 208 for storing pixel image resulting from running program (c. 4, 11. 36-37; c. 9, 11. 33- 
36; c. 1,11.55-58). 

It would have been obvious to one of ordinary skill in the art at the time of invention by 
applicant to modify Grantham and McCrossin to include 3^** memory for storing pixel image 
resulting from running program because Hoppe suggests it is well-known in the art to have frame 
buffer in video memory to store rendered image so that rendered image can be output from video 
memory to display (c. 4, 11. 36-37; c. 9, 11. 33-36). 
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88. As per Claim 23, Grantham teaches and 2^^ memories are the same (Fig. 1; c. 4, 11. 1 8- 
21; c. 5,11. 2-23). 

89. As per Claim 25, Grantham teaches 1^* and 2°'* memories are in system memory (1 1 0, 
Fig. 1; c. 4, 11. 18-21; c. 5, 11. 2-23) 

However, Grantham does not teach third memory is in video memory. However, Hoppe 
teaches this limitation (208; c. 4, 11. 36-37). This would be obvious for reasons for Claim 22. 

90. As per Claim 26, Grantham teaches first microprocessor (108, Fig. 1) processes data 
structure to produce program for use on second microprocessor (109) (c. 4, 11. 63-c. 5, 11. 1 1). 

91 . As per Claim 27, Grantham teaches second microprocessor (109, Fig. 1), under control of 
program causes pixel image to be output (c. 5, 11. 2-1 1). 

But, Grantham doesn't teach image is stored in 3^** memory. But, Hoppe teaches 2°'* 
processor 206, under control of program causes pixel image to be stored in 3^** memory 208 (c. 4, 
11. 36-44; c. 9, 11. 33-36; c. 1, 11. 55-58; c. 2, 11. 20-26). This is obvious for reasons for Claim 22. 

92. Claim 24 is rejected under 35 U.S.C. 103(a) as being unpatentable over Grantham 
(US006215495B1), McCrossin (US006600840B1), and Hoppe (US006919906B2) in view of 
Sturges (US005854637A). 

Grantham and McCrossin are relied on for teachings relative to Claim 22. Grantham 
teaches first and second memories are system memory (Fig. 1; c. 4, 11. 18-21; c. 5, 11. 2-23). 
Hoppe teaches third memory is frame buffer (208; c. 4, 11. 36-37), as discussed for Claim 22. 

But, Grantham, McCrossin do not teach 1^*, 2°'*, 3^"* memories are the same. But, Sturges 
teaches using shared memory for both system memory and frame buffer (c. 3, 11. 7-15). So 
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combination of Grantham, McCrossin can be modified so l*** and 2""* memories in system 
memory of Grantham, frame buffer of Hoppe are in the same memory as suggested by Sturges. 

It would have been obvious to one of ordinary skill in the art at the time of invention by 
applicant to modify Grantham and McCrossin so 1^, and 3^** memories are the same because 
Sturges teaches using unused portions of frame buffer as system memory (c. 1, 11. 35-41). 

93. Claims 30-32 and 45-47 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Grantham (US006215495B1) in view of Boudier (US006995765B2). 

94. As per Claim 30, it is similar in scope to Claim 4, and so is rejected under same rationale. 

95. As per Claim 31, Grantham does not teach step of optimizing graph representing first 
image comprises step of analyzing adjacent nodes in graph for purpose of attempting to 
consolidate nodes. However, Boudier teaches this (c. 9, 11. 40-53; c. 8, 11. 4-10). 

It would have been obvious to one of ordinary skill in the art at the time of invention by 
applicant to modify Grantham so optimizing graph representing first image comprises analyzing 
adjacent nodes in graph for piupose of attempting to consolidate nodes because Boudier teaches 
this reduces the number of nodes, so reduces memory usage, and drawing time is reduced 
because there will be fewer fimction calls (c. 8, 11. 20-24; c. 9, 11. 40-53). 

96. As per Claim 32, it is similar in scope to Claim 3 1 , so is rejected under same rationale. 
As per Claims 45-47, these claims are similar in scope to Claims 30-32 respectively, so are 
rejected under same rationale. 

97. Claims 33 and 48 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Grantham (US006215495B1) and Boudier (US006995765B2) in view of Levy (US 
20020033844A1). 
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Grantham and Boudier are relied upon for teachings as discussed relative to Claim 3 1 . 

But, Grantham doesn't teach analyzing adjacent nodes and storing result of such analysis 
in memory. But, Boudier teaches this (c. 9, 11. 40-53; c. 8, 11. 20-21). This would be obvious for 
reasons for Claim 3 1 . 

But, Grantham and Boudier do not teach checking cache to determine if result of such 
analysis is available in memory. But, Levy teaches step of checking cache to determine if pixel- 
image result is available in memory [0184, 0021, 0038]. This is obvious for reasons for Claim 3. 

98. Claims 34, 35, 49, and 50 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Grantham (US006215495B1) in view of Levy (US 20020033844A1). 

99. As per Claim 34, Grantham is relied on for teachings for Claim 28. Grantham teaches 
step of optimizing graph and storing optimized graph in memory (c. 4, 11. 55-58; c. 2, 11. 54-67). 

However, Grantham does not teach step of checking cache to determine if graph has 
already been optimized. But, Levy teaches step of checking cache to determine if pixel-image 
result is already in memory [0184, 0021, 0038]. This would be obvious for reasons for Claim 3. 

100. As per Claim 35, Grantham teaches step of optimizing graph and outputting result of 
rendering graph (c. 4, 11. 55-58; c. 5, 11. 2-23). 

But, Grantham does not teach step of checking cache to determine if result of rendering 
graph is available in memory. But, Levy teaches step of checking cache to determine if pixel- 
image result is available in memory [0184, 0021, 0038]. This is obvious for reasons for Claim 3. 

101 . As per Claims 49 and 50, these claims are similar in scope to Claims 34 and 35 
respectively, and so are rejected under same rationale. 
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102. Claims 42 and 57 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Grantham (US006215495B1) in view of Stokes (US006977661B1). 

Grantham is relied on for teachings for Claim 28. Grantham teaches 2°^ process inserts 
nodes into graph (c. 5, 11. 2-23) for performing certain functions (c. 4, 11. 23-49). 

However, Grantham does not teach functions include functions for converting original 
color scheme to operating color scheme and for converting operating color scheme back to 
original color scheme. However, Stokes teaches this limitation (c. 5, 11. 63-67). 

It would have been obvious to one of ordinary skill in the art at the time of invention by 
applicant to modify Grantham so 2nd process inserts nodes into graph for converting original 
color scheme to operating color scheme and for converting operating color scheme back to 
original color scheme because Stokes suggests this is needed because color data generated by 
image-capturing device are generally in device-specific color space that is different from color 
space or spaces used by image-processing application for image editing (c. 1, 11. 40-44). 

103. Claims 59 and 64 are rejected mder 35 U.S.C. 103(a) as being unpatentable over 
Grantham (US006215495B1) and McCrossin (US006600840B1) in view of Doyle 
(US00687779B1). 

Grantham and McCrossin are relied on for teachings discussed relative to Claim 58. 

However, Grantham and McCrossin do not teach request is serviced using GPU and 
CPU. However, Doyle teaches request is serviced using GPU and CPU (c. 2, 11. 1-3). 

It would have been obvious to one of ordinary skill in the art at the time of invention by 
applicant to modify Grantham and McCrossin so request is serviced using GPU and CPU 
because Doyle teaches this accelerates speed by which 3-D image can be rendered (c. 1, 11. 7-10). 
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104. Claims 76-77 are rejected under 35 U.S.C. 103(a) as being unpatentable over Boudier 
(US006995765B2) in view of Levy (US 20020033844A1). 

105. As per Claim 76, Boudier is relied on for teachings for Claim 75. Boudier teaches 
determining if 1^* node may be combined with node, result is stored in memory (c. 9, 11. 40- 
53; c. 8, 11. 20-21). 

But, Boudier does not teach step of checking cache to determine if there is result is 
already in memory regarding such determination regarding combining nodes. But, Levy teaches 
step of checking cache to determine if pixel-image result is already in memory [0184, 0021, 
0038]. This would be obvious for the same reasons given in the rejection for Claim 3. 

106. As per Claim 77, Boudier teaches step of resolving first node and storing resolution of 
first node in memory (c. 9, 11. 40-53; c. 8, 11. 20-21). 

However, Boudier does not teach step of resolving first node comprises step of checking 
cache to determine if there is result in memory regarding resolution of first node. However, Levy 
teaches step of checking cache to determine if pixel-image result is already in memory [0184, 
0021, 0038]. This would be obvious for the same reasons given in the rejection for Claim 3. 
Conclusion 

THIS ACTION IS MADE FINAL. Apphcant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
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will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 

CFR 1.136(a) will be calculated from mailing date of advisory action. In no event, however, will 

statutory period for reply expire later than SIX MONTHS from mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to JONI HSU whose telephone number is (571)272-7785. The 
examiner can normally be reached on M-F 8am-5pm. 

If attempts to reach the examiner by telephone are unsuccessfiil, the examiner's 
supervisor, Kee Tung can be reached on 571-272-7794. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an apphcation may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Elecfronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
JH 

/Kee M Tung/ 

Supervisory Patent Examiner, Art Unit 2628 



